체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

현재 구조는 Player → CardBundle → Card처럼 객체가 서로를 참조하고 있는데, 일부 로직에서 이미 Player 객체를 전달받고 있음에도 불구하고 CardBundle에 직접 접근해 점수를 계산하는 코드가 있었습니다.
이 경우 특정 클래스가 여러 도메인의 내부 구조를 알고 있어야 한다는 점이 걸렸습니다.
그래서 외부에서 CardBundle에 직접 접근하는 대신, Player에게 점수를 요청하고 Player가 내부적으로 CardBundle에 위임하는 구조로 변경했습니다. 이렇게 하면 외부에서는 Player의 내부 구조를 알 필요가 없어지고, 나중에 카드 관리 방식이나 점수 계산 로직이 바뀌더라도 다른 도메인이나 레이어의 변경을 줄일 수 있지 않을까 생각했습니다.
구현을 진행하면서 이런 방식이 위임 메서드라는 개념과도 연결된다는 것을 알게 되었습니다.
사이클1 리뷰에서 지식을 받아가는 취지보다 제 생각이 상대를 설득할 수 있을지에 초점을 맞춰보라는 말씀을 해주셨는데, 이번에는 그 조언을 떠올리며 제 나름의 기준으로 구조를 선택해 보았습니다.
제가 이런 방향으로 접근한 것이 어느 정도 타당한 방향인지, 또 이런 상황에서 추가로 고려해 볼 만한 부분이 있는지도 의견을 듣고 싶습니다.

판정과 수익 계산 책임 분배에서 겪은 어려움도 있었습니다.
베팅 기능을 구현하면서 판정 결과와 베팅 금액을 이용해 수익을 계산하는 책임을 어디에 두어야 할지 고민이 많았습니다.
처음에는 관련 책임을 Bet 도메인에 모으려고 생각했습니다. 하지만 구현을 진행하면서 판정 로직, 플레이어 상태, 베팅 금액 등 여러 도메인이 함께 관여하게 되었고, 어느 객체에 책임을 두는 것이 자연스러운지 판단하기가 쉽지 않았습니다.
그래서 여러 방향으로 구조를 바꿔 보면서 계속 수정을 진행했던 것 같습니다. 그 과정에서 특정 객체가 너무 많은 정보를 알게 되는 구조가 되기도 했고, 반대로 책임이 지나치게 분산되는 느낌도 있었습니다.
여러 시도를 거친 끝에 현재 구조를 선택하게 되었지만, 이 선택이 최선인지에 대해서는 아직 확신이 서지는 않습니다.
아루가 보시기에는 이 문제를 고민하는 과정에서 제가 놓치고 있는 부분이 있는지, 혹은 이런 상황에서 책임의 위치를 판단할 때 어떤 기준으로 접근하시는지 궁금합니다.

그리고 지난 리뷰에서 좋은 피드백을 많이 남겨주셔서 감사했습니다. 단순히 수정할 부분을 짚어주시는 것뿐만 아니라, 어떤 관점에서 고민해보면 좋을지까지 말씀해주셔서 이번 사이클을 진행하면서 여러 번 다시 떠올리게 되었습니다. 덕분에 이번에는 이전보다 설계에 대해 조금 더 깊게 고민해보려고 노력했습니다.

아직 제가 놓치고 있는 부분도 많을 것 같고, 방향이 완전히 맞는지에 대한 확신도 부족한 상태이지만 그래도 나름대로 생각해본 과정들을 정리해보았습니다. 이번에도 부족한 부분이 있다면 편하게 말씀해주시면 감사하겠습니다. 잘 부탁드립니다.😊